Session Initiation Protocol (SIP) forking is the ability of a SIP proxy server to fork SIP request messages to multiple destinations according to IETF RFC 3261. This allows the Internet Protocol (IP) Multimedia Subsystem (IMS) to send an incoming SIP request addressed to a Public User Identity to multiple terminating end points when multiple contact addresses have been registered for the same Public User Identity.
Support for SIP forking in the IMS is specified in 3GPP TS 23.228, and the related User Equipment (UE) procedures are described in 3GPP TS 24.229. Support for SIP forking when policy control is applied is specified in 3GPP TS 29.214.
The typical use case is as follows. A connected UE initiates an IMS session by sending an INVITE request to a Proxy Call Session Control Function (P-CSCF). The P-CSCF forwards the INVITE towards a Serving Call Session Control Function (S-CSCF) and then the S-CSCF towards a terminating IMS network. The terminating IMS network sends the request in parallel to multiple registered contact addresses for the called party, creating several early dialogs from a single request. Each terminating end point sends a preliminary SIP response and, after successful SDP negotiation, starts ringing. The terminal that answers the call sends a final 200 OK (for INVITE) response, and the communication path is established to this particular end point, whilst all other early dialogs are cancelled or released.
As a result, the originating P-CSCF may receive multiple preliminary SIP responses due to forking, as multiple early media sessions may be established before the final SIP response is received. When policy control is applied, a Policy and Charging Rules Function (PCRF) is contacted for each early media session as it needs to be authorized, and the allocated resources may need to be updated when subsequent preliminary responses are received, according to the resources needed by each early dialog.
Policy control is initiated when the P-CSCF establishes a Diameter session with the PCRF over an Rx reference point as part of the establishment of a SIP session. This can occur when the originating UE initiates the SIP request or upon reception of the first preliminary/final SIP response for the SIP request. This Diameter session is reused for each subsequent preliminary/final SIP response received as part of the same SIP session in order to provide additional or modified service information.
The UE and the P-CSCF become aware of the forking only when a subsequent preliminary SIP response arrives for a new early dialogue.
According to 3GPP TS 29.214, after the first early media session is established, for each subsequent preliminary SIP response establishing an additional early media session, the P-CSCF shall use an AA-Request (AAR) message within the existing Diameter session containing the SIP-Forking-Indication Attribute Value Pair (AVP) with the value SEVERAL_DIALOGUES and include the service information derived from the latest preliminary SIP response. An AA-Request (AAR) message is acknowledged towards the P-CSCF with an AA-Answer (AAA) message. For the sake of simplicity, AAA messages are neither further commented throughout this specification nor illustrated in any drawing.
In addition, the P-CSCF provisions the service information derived from any subsequent Session Description Protocol (SDP) offer-answer exchange within an early dialogue (e.g. in PRACK and 200 OK (PRACK), or UPDATE and 200 OK (UPDATE)) using an AAR message within the existing Diameter session containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES and the derived service information.
When receiving an AAR message containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, the PCRF shall authorize any additional service data flow filters, any additional media components and any increased Quality of Service (QoS) requirements for the previously authorized media components, as requested within the service information. The PCRF shall authorize the maximum bandwidth required by any of the dialogues, but not the sum of the bandwidths required by all dialogues. The reason is that there will be early media sent from only one of the early dialogs, not from all the early dialogs. The PCRF shall also open or close the gates for service flows depending on the flow status that is being provisioned.
According to 3GPP TS 29.214, the P-CSCF shall store the SDP information for each early dialogue separately till a final SIP response is received. When the final SIP session is established, all the other early dialogues are terminated and the service information for the SIP session is updated to match the requirements of the remaining early dialogue only.
When receiving the first preliminary/final SIP response, the P-CSCF sends an AAR message without the SIP-Forking-Indication AVP and includes the service information derived from the SDP corresponding to the dialogue of the preliminary/final response. The PCRF updates the installed Policy Control and Charging (PCC) Rules information and Authorized-QoS information to match only the requirements of the service information within this AAR message, and also to open or close the gates for service flows according to the flow status in the received service information.
The Customized Alerting Tones (CAT) service is an IMS terminating service that triggers an external Customized Alerting Tones Server (CAT-S) to generate a customized signal (customized welcome message or selected music) towards the caller when the served user is alerted. The service allows an end user to define the customized alerting tones to be played, and is sometimes called Personal Ring Back Tone.
The Network Provided Ring Back Tone (NRBT) service is an IMS terminating service that triggers a Multimedia Resource Function Processor (MRFP) to generate an NRBT signal (customized welcome message or ringing tone) towards the caller while the served user is alerted. The tone is common for all the IMS subscribers and is only configurable by an operator.
A common model to perform the CAT or NRBT service is by using the so called forking model. This means that an Application Server (AS) in the terminating side (either the Telephony Application Server (TAS) or the CAT-S) is simulating to be a forking leg. Hence, when the 180 Ringing message is received from the remote UE, the AS initiates a provisional early media session where the customized alerting tone is played. Finally, when the remote UE answers the call, the AS stops the ring back tone and forwards the final answer to establish the communication path between both parties.
Support for the CAT service in IMS is specified in 3GPP TS 24.182. Examples of signalling flows for the CAT service within the IMS subsystem can be found in 3GPP TS 24.182 Annex A.3
According to 3GPP TS 23.228, QoS-assured preconditions can be negotiated during IMS session establishment to ensure that resources are available in the network before the called subscriber is alerted, thus when the called subscriber answers the call the users are guaranteed to be able to communicate.
The usage of preconditions is strongly recommended as it prevents the problem of ghost ringing, i.e., that the call appears to be connected, but the users cannot talk with each other.
However, the usage of pre-conditions implies more SIP signaling during the session establishment and several invocations from IMS to the packet core network to update the resources with new session information during call establishment.
The Rx Flow-Number AVP, hereinafter referred to as flow identifier, is an ordinal number starting from 1 that identifies the IP flow within the media component (i.e. it identifies the traffic related to certain service for certain media, e.g. audio traffic). For a SIP session, the flow identifiers are derived from the SDP information as the ordinal number of the position of the “m=” line in the SDP, according to the following rules in 3GPP TS 29.214 Annex B.1.2.
The procedure guarantees that UE and Application Function (AF) assign the same ordinal number to each media component for a given application. Also, the ordinal number of a media component shall not be changed when the session description information is modified.
This means that all multiple preliminary SIP responses due to SIP forking will result in the same flow identifiers being sent from the P-CSCF to the PCRF.
The current support for SIP forking, as specified in 3GPP TS 29.214, does not allow the P-CSCF to modify the session information of a particular preliminary forking response.
This limitation comes from the fact that all preliminary responses due to forking make use of the same Diameter Rx session, and the SIP-Forking-Indication AVP can only have the value: SINGLE_DIALOGUE (0), or SEVERAL_DIALOGUES (1). In addition, the flow identifiers (Flow-Number AVP) derived by the P-CSCF for all preliminary responses overlap, as they are based on the Session Description Information (SDI) exchanged between the AF and the AF session client in the UE.
Hence, the PCRF will identify any AAR message containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, as a new preliminary forking response from another terminating end point, when it may actually be a modification of the session information for a previous forking response. In this situation the PCRF will authorize the received service data flow filters as additional IP flows, when the wanted behavior is to modify the information provided in the existing PCC rules.
The main disadvantage of the existing solution is that the additional IP flows need to be notified to the UE for policy enforcement in the uplink path.
The P-CSCF may need to modify the session information of a preliminary forking response in the following situations.                When the P-CSCF provides preliminary service information not fully negotiated yet (e.g. based on the SDP offer), and then updates the service information with the SDP answer.        If the P-CSCF needs to enable or disable media IP flows depending on operator policy prior to the completion of the SIP session set-up, thus allowing or forbidding early media in forward and/or backward        When the SIP terminal makes use of QoS preconditions        
FIG 1. shows current support for SIP forking policy control in 3GPP. The P-CSCF cannot modify the session information of a particular preliminary forking response, as required in step S-108. Hence, the P-CSCF provisions the new service information (SDP_b_update) as an additional early media session (step S-109). The PCRF believes that this is a new preliminary SIP response and then modifies the already provided PCC rules to include the service data flow filters provided in the latest AAR message (step S-111).
Since the PCRF believes that it is a new preliminary SIP response, the updated PCC rule will include the flow information as provided by the P-CSCF, as it is considered that, as it is coming from a different forking leg, it will be different from the previously provided information (different IP address/port from the terminating side). However, if the AAR message is referring to a modification of the session of an existing forking response where for example only the gate status is changed (e.g. enabled media flows are now disabled), the flow information has been already provided as part of a PCC Rule to the packet core network.
Upon reception of an updated PCC rule that contains service data flows, the enforcement point in the network (e.g. Packet Data Network Gateway, PGW) will initiate a bearer update procedure in order to provide the UE with the service data flows included in the PCC rule. This would create an unnecessary signalling towards the UE, as the terminal is already aware of this filter information.
Different alternatives can be considered in order to solve the problem:                Impact in the P-CSCF: The P-CSCF can check whether the received SIP response corresponds to the modification of an existing SIP dialogue or it refers to a new dialogue. In the first case, the P-CSCF would have to check, from the SDP data, which information has been already provided to the PCRF and which information is different from the already provided one. The P-CSCF would only provide the updated/new service information.        Impact in the PCRF: In order for the PCRF to identify that the service data flow information is the same than the previously provided would require that the PCRF checks, for each AAR command received with the SIP-Forking-Indicator, that the previously generated PCC rules already installed in the PGW have the same filter information.        Impact in the PGW: in order for the PGW to identify that the provided filter information has been already provided to the UE, it would have to retain the previously provided filter information and check it against the filter information provided in the PCC Rule.        
The three alternatives have a strong performance impact and latency requirements that invalidate them as feasible solutions.